Journey to a software-defined access fabric network, part 1 – Cisco Blogs
Cisco IT has powerful motivations to shift to a software-defined access (SDA) fabric network, as part of our ongoing journey to an advanced network architecture. In this blog I will explain these motivations. In part 2 (coming soon), I’ll share our guiding principles, how we did it, and payoffs to date.
Over the last several years, demands on the Cisco campus network have skyrocketed. Think application-centric infrastructure (ACI). Software-defined WAN. Cloud firewalls. To manage a constantly evolving network, we need stronger security and faster policy changes. Specifically, that means getting rid of access control lists (ACLs), manual switch configuration, static VLANs, and separate access policies for different places in the network.
Cisco’s network changes frequently because of acquisitions, divestments, new teams, new kinds of endpoints, etc. Some changes are forecasted and planned, like our transformation to Smart Buildings by adding Internet of Things devices like cameras, digital signage, and sensors. (Here’s my blog on IoT in non-carpeted spaces like garages.) Other changes nobody forecasted, like our current need to plan a safer return to the office in the wake of COVID-19 by measuring building occupancy and employee proximity.
To securely add new devices, we need to control who and what has access to specific resources. The traditional solution is to configure routers and firewalls with discrete ACLs that specify allowed source and destination IP addresses, ports, and protocols. The problem? What our users could access depended on how they were connecting to the network. That’s impractical if people work from home, for instance. Another problem: every device has its own ACL. At Cisco, that means deploying them on hundreds of firewalls and thousands of routers. ACLs are often thousands of lines long and include contributions from dozens of engineers over many years. Mistakes are inevitable. Some mistakes can allow unauthorized access or, conversely, prevent employees from accessing the services they need to do their jobs.
What’s better with SDA.
No more ACLs. Now we build the access policy just once, on Cisco Identity Services Engine (ISE). We use Cisco DNA Center to create scalable group tags (SGTs) for the different types of users connecting to our network: guest, employee, contractor, or partner. We have a special tag for devices that don’t do 802.1X authentication, like printers, security cameras, and sensors. Say a contractor tries to connect to the wireless network from a laptop. ISE authenticates the laptop using 802.1X and then assigns the “contractor” tag, which accompanies all traffic from the laptop. Every switch, router, or firewall along the way looks at the tag to see which VLANs and applications the laptop can access. Defining security policy just once—not individually on every network device—saves time and reduces configuration errors that weaken security.
SDA’s secure segmentation model really showed its power when we needed the network to adapt to enable a safer return to office. We certainly hadn’t built this exact scenario into the original design, but SDA with Cisco DNA Center gave us the flexibility to quickly enable RTO location analytics with Cisco DNA Spaces, and to plan for additional sensor deployments.
Configuring individual switches during fleet upgrades can easily take an hour per switch. Engineers often cut and paste configurations from Word or Excel documents. Errors are bound to happen.
What’s better with SDA.
Automated device configuration—no more cutting and pasting. We use Cisco DNA Center to push a validated configuration that we know is supportable and stable, bringing peace of mind.
In the past, when a Cisco team asked to connect a new kind of endpoint to the network—say, an IP security camera or building management system—we built a static VLAN. Compiling the design generally took months, and design review took weeks. Another problem was that some of our older switches don’t support TrustSec, so we had to manually map IP addresses to SGTs using the SGT Exchange Protocol (SXP). That’s time consuming, and a large number of mappings can tax the switch’s CPU and memory.
What’s better with SDA.
Instead of using static VLANs, we now use Cisco DNA Center to create specific policies for each type of device. After a quick design review and testing, we push the new configuration everywhere it needs to be in a couple of minutes. We don’t have to worry about whether older switches support TrustSec, because any device that supports IP routing supports SGTs.
With SDA, the time to make changes such as new access policies shrank from weeks to days. The time to implement thousands of switches and routers sped up from months to days.
Before, we had to create separate access policies based on where the user or device connected. For each domain (WAN, data center, Internet), we’d create a policy that applied specifically to one VLAN or IP subnet. Other domains couldn’t see the policy, so we had to manually program switches to translate policies from one domain to another. Design and implementation often took weeks.
What’s better with SDA.
Now we define access policies once, and they’re consistently enforced everywhere in the network. SGTs travel with traffic everywhere it goes, so there’s no need to configure separate policies for the WAN, data center, and internet. This makes it easier for us to set up the zero-trust networking needed in a hybrid cloud environment. No matter where and how a user connects, we have a consistent policy from end to end.
In part 2 of this blog series, we’ll explain how we implemented the SDA fabric and the value we’re seeing.
Learn more about our journey to an advanced network
architecture by clicking through our interactive journey map
Follow Cisco IT on social!
Share:
